In a processing system that includes multiple shelves, where each shelf includes multiple processing cards, an operations, administration, and maintenance (OAM) subsystem is typically employed to monitor and control the various hardware and software components present in the processing system. The functions of an OAM subsystem may for example include identifying and configuring hardware and/or software components present in the system, monitoring the status, events, and alarms associated with those components, and detecting a change made to the processing system, such as addition and removal, and activation and deactivation of those components. The OAM subsystem may include a graphical user interface (GUI), command line interface (CLI), or both, through which the processing system may be monitored and controlled.
An OAM subsystem architecture may use the Hardware Platform Interface (HPI), an interface standard defined by the Service Availability Forums (SAF). HPI provides a universal interface for platform management, including hardware sensor monitoring and control. HPI provides an abstracted interface to managing computer hardware, typically for chassis- and rack-based servers. HPI includes an abstract C programming language library interface for hardware monitoring, control, and management. The HPI standard interface supports resource modeling; access to and control over sensor, control, watchdog, and inventory data associated with resources; abstracted system event log interfaces; hardware events and alerts; and a managed hotswap interface. HPI provides a modular mechanism for adding new hardware and device support easily. The HPI-based architecture includes an HPI daemon, or background process, where the HPI daemon is a user of the HPI library that provides HPI as a system service. Other processes that wish to communicate with the HPI daemon may make use of a provided HPI client side library.
A centralized HPI daemon communicates with all shelves and cards that comprise the system. It also communicates with any number of OAM software processes. The centralized HPI daemon may read the configuration information, such as the number of shelves in the system, from a configuration file at start-up. The centralized HPI daemon may not have the capability to allow the user to specify its IP address and port via a command line argument, but instead may require the user to define system environment variables prior to starting the daemon; at initialization, the daemon may read these system environment variables to determine its assigned IP address and port.
FIG. 1 is a block diagram illustrating a conventional OAM subsystem architecture. A multi-shelf, centralized HPI processing system 100 includes shelves 102, each of which may contain one or more cards 104, which may perform various functions. An HPI daemon 106 communicates OAM-related information with all shelves in system 100. System 100 may contain OAM software processes, such as process 1 108 and process 2 110. HPI daemon 106 acts as the interface between OAM software processes and the hardware components in the system, communicating OAM-related information between the processes and the hardware components.
There are disadvantages associated with a conventional implementation of the current HPI standard. One disadvantage is that a single, centralized HPI daemon becomes a significant bottleneck for OAM-related traffic in system 100. Another disadvantage associated with the conventional implementation is that centralized HPI daemon 106 must be taken out of service or rebooted whenever a new shelf is added to system 100, because HPI daemon 106 reads the updated configuration file including information about the new shelf only upon a start or restart. Where all shelves in an OAM subsystem rely on the same HPI daemon, whenever a shelf is added to, or removed from, system 100, all shelves are taken out of service while HPI daemon 106 restarts.
Accordingly, in light of these disadvantages associated with OAM subsystem architectures based upon the conventional implementation of the current HPI standard, there exists a need for a distributed HPI architecture.